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[57] ABSTRACT 

The present invention discloses a method, computer pro- 
gram product, and system for dynamically and program- 
matically modifying the semantics and/or logic of class files 
as they are being loaded for execution. The present invention 
permits a user to write a control file specifying in a pro- 
grammatic manner the changes to be applied to class files 
and the conditions for carrying out the changes. As the class 
files are loaded, they are analyzed for the desired conditions 
and if the conditions are found, the control file is applied to 
them to effect the appropriate changes according to the 
user's control file. 

9 Claims, 5 Drawing Sheets 
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APPARATUS AND METHOD FOR 
DYNAMICALLY MODIFYING CLASS FILES 
DURING LOADING FOR EXECUTION 

FIELD OF THE INVENTION 

The present invention relates generally to computer pro- 
gramming methods and systems, and, in particular, to meth- 
ods and systems for modifying compiled programs dynami- 
cally and program matically, without resort to source code. 

BACKGROUND OF THE INVENTION 

Computer languages and environments generally employ 
three types of methods for translating source code written by 
a programmer into machine instructions. In interpreted 
environments, each statement or command of source code is 
translated to machine language as the program runs, one or 
a few statements at a time. An example of an interpreted 
environment is the Restructured Extended Executor 
(REXX) language specified by IBM and supported on 
IBM's Virtual Machine (VM) and OS/2™ operating sys- 
tems. In compiled environments, each part of a program is 
translated into machine code and the several parts are linked 
together into a machine code executable file for a specific 
machine before the program is distributed or run. Compiled 
environments include C, C++, FORTRAN, and most main- 
stream programming languages. A third type of environment 
is a virtual machine environment as shown in FIG. 1, in 
which a program is translated 105 into a pseudo-machine 
code 115, which runs on a machine specification which may 
be implemented in a hardware machine or may be imple- 
mented as a "virtual machine" 125 in software on several 
hardware and operating system platforms 130, before being 
run. This third environment allows the translated program to 
be run on every hardware and operating system environment 
on which there is a compliant implementation of the virtual 
machine. The present invention is directed toward virtual 
machine environments, the most prominent of which is the 
Java™ environment, recently released by Sun 
Microsystems, in which the pseudo- machine code is also 
called bytecodc, and the files that contain the bytccode and 
other information needed to load and run programs are 
called class files. The terms bytecode and class file are used 
generically herein to specify, respectively, the pseudo- 
machine code to be interpreted by a virtual machine envi- 
ronment and the files which contain bytecodes and other 
information needed to load and run programs in virtual 
machine environments, respectively. Use of these terms is 
not intended to restrict the invention to the present JavaTm 
architecture, or to the Java™ language. 

In virtual machine environment systems, programs and 
program parts are usually distributed in class files, with the 
source code not generally being made available. In some 
environments it may be desirable to derive the original 
source code from the class files, and in the Java™ world 
there are several tools available to do this derivation. These 
tools include a tool named Mocha, written by the late 
Hanpeter van Vliet and available at hup:// 
www.brouhaha.com/-eric/computers/mocha.html, and 
another tool named D-Java, written by Shawn Silverman 
and available at http://home.cc.umanitoba.ca/-umsilvel/ 
djava/. Many authors of Java™ programs do not want their 
class files to be translated back to source code, a process 
known as disassembly. These authors may resort to another 
set of tools available in the Java™ world called obfuscators, 
which operate as shown in FIG. 3. Obfuscators modify 
Java™ class files 300 to make them difficult to understand 
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if they are disassembled using tools like the Mocha or 
D-Java disassembers. An example of an obfiiscator is the 
hashjava tool, by KB Sriram and available at hup:// 
webx.best.com/-kbs/hashjava.html. Obfuscators do not 

5 modify the logic and/or semantics of Java™ class files; they 
perform simple transformations on names to make them 
harder to understand, and they do not allow the user flex- 
ibility to do anything else with class files that would change 
their logic or semantics. Some obfuscators do not allow the 

10 user flexibility to affect how the class files are transformed, 
and others such as the hashjava tool only allow the user the 
capability to specify simple transformations 320 that will be 
performed on the names. 

One may desire to modify the logic and/or semantics of 

15 class files without having the original source available. For 
example, in the area of security, one may wish to have a 
capability to "scrub" class files to prevent them from execut- 
ing any instructions that may cause a security risk. In the 
prior art, the Java™ Virtual Machine (JVM) 125 has a 

20 "bytecode verifier" function that examines class files to 
verify that they are not performing risky operations. How- 
ever the bytecode verifier does not have any capability for 
modifying class files found to be troublesome — it simply 
refuses to load them. 

25 Another area in which one may desire to modify the logic 
or semantics of class files with no source code available is 
to enable different pieces of a program to be dynamically 
distributed across several computers, without requiring the 
programmer to be aware of such distribution, as in the 

30 invention described in the copending, commonly assigned 
patent application having Ser. No. 08/852,263, entitled "A 
Process for Running Objects Remotely," filed on May 6, 
1997. 

35 Further reasons to modify class file logic or semantics 
include, but are not limited to, performance optimization, 
performance and error tracing and notification, etc. 

Digital Equipment Corporation's Analysis Tools with OM 
(ATOM) tool provides for programmatic modification of 
compiled code for the compiled environment without resort 
to source code. The ATOM tool is designed to add calls to 
analysis and measurement routines, not to alter the logic and 
semantics of a program. Additionally, as the ATOM tool is 
designed to operate in the compiled environment, it has no 

4S capabilities for modifying compiled code as it is loaded to be 
run, and the ATOM tool works only on compiled code for 
Digital Equipment Corporation's supported machines. More 
information on the ATOM tool is available at http:// 
www.research.digital.com/wrl/projects/om/om.htmL 

50 Using the teachings of the prior art, there are several 
unappealing methods available for modifying class files for 
virtual machine environments such as the Java™ environ- 
ment. 

1. Class file modification could be done by hand, as shown 
55 in FIG. 2, using the disassemblers of the prior art 205 to 
derive source code 210, modify it by hand 215, and recom- 
pile 225 it into a class file 230 again. If one is particularly 
skilled in the art of the language being used and is familiar 
with the formats of bytecodes and class files, one may also 
60 directly manipulate class files by hand (235 and 240). 
However, this process is tedious and error prone, and 
particularly inefficient if many parts must be modified in 
similar ways that could be described programmatically. 
Furthermore, one may desire to do class file modification 
65 dynamically, as the bytecode files are being loaded for 
execution, especially if said bytecode files are being loaded 
from a remote server, and therefore are not available to the 
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local machine before they are to be run. It obviously would lion is controlled by a program written by a user, which 

not be desirable to do such dynamic, load-time modification permits the user virtually unlimited control over the types of 

by hand. modifications to be performed. When the extended class 

2. Class file modification could be done with a tool which loader obtains a class file to be loaded, it passes the class file 
makes specific transformations, as shown in FIG. 3, for 5 to an interface implementing the process disclosed in the 
example changing commands that may pose a security risk present invention. The disclosed process determines, using a 
into harmless or ineffective commands. Such a tool would decision specification provided by the user, if modifications 
work similarly to an obfuscator, ^searchmg^r.specific are needed to the class file, and if so they are applied 
sequences in the class file and changing th em to so me .other-' according to a modification specification provided by the 
sequence. Such tools may even allow for the use of "pro- ™ user- After the transformations are complete, the modified 
files" 320 or other methods of exporting to the user 325 class file is returned to the normal class loader processing 
choices such as what sequences are to be changed into what and loaded as is normally done. The result of this process is 
other sequences, or giving a mapping from an existing that the user's desired transformations may be automatically 
sequence to a new sequence that is to replace the existing applied to all class files loaded and run in the virtual 
sequence. Such a method would simply represent the auto- 35 machine. 

mation of the first method mentioned above. 

3. Class file modification could be done with a program 
such as the ATOM tool, which would allow a programmatic The preferred embodiment of the present invention will 
and flexible interface for making changes to the compiled be herein described in more detail with reference to the 
code. While a program such as the ATOM tool would allow 20 drawings, in which: 

the user flexibility to add and change compiled code in a FIG. 1 depicts a general overview of the development and 

programmatic way, such a tool contemplates adding analysis loading of code in a prior art virtual machine environment, 

and measurement routines, and does not contemplate modi- FIG. 2 depicts the prior art methods for modifying a class 

fications in the logic or semantics of the modified code. Also, file wheQ lhe original source code is not available, 

the ATOM tool does not teach or suggest modifying code in . f . , 

. r . j • u • i j -i r FIG. 3 depicts the prior art methods for using tools to 

an automatic fashion as such code is being loaded tor r r , . . . ° . 

t . , - , , t u t ■ t u make modifications to a class file when the original source 

execution, since the concept of a class loader is absent in the . ° 

... . , . . ATnu t , . code is not available, 
compiled environments for which the AIOM tool is 

designed FIG. 4 depicts loading and modification of a class file 

„ * 30 using the preferred embodiment of the present invention 

Hence, none of the prior art teaches or suggests a method * 5 . *\ . t . .. , . . _ 

. ... j j-c . i j .• • — — when the ongmal source is not available, using a program- 

for dome bytecode modification at load time in a program- . * . ,.~ . ^ , ~ . 

B 3 r & matic API to specify the modifications to be made, 
ma tic way. 

FIG. 5 depicts in more detail the class file modification 

OBJECT OF THE INVENTION ^ process shown in FIG. 4. 

It is the object of the present invention to provide a DETAILED DESCRIPTION OF THE 

method for programmatically modifying class files without PREFERRED EMBODIMENT 

need of resort ine to their source files, and to perform said . . 

,. c . r i «i j -11 nr. fn'A fiioe n M Kjiinrt The present invention is applicable to any dynamic modi- 

modification of class files dynamically, as said files are being . *r 3 3 

. , . f . J ° n fication of bytecodes or class files as they are loaded to be 

loaded for execution. ™ , J . _ M , . . . .■ n • 

executed. The Java™ Object Instrumentation Environment 

SUMMARY OF THE INVENTION ( J0IE ) of the preferred embodiment utilizes the Java™ 

programming environment although the present invention is 

The present invention includes a method, system, and no t limited to the Java™ environment and the application of 

program product for modifying class files dynamically and ^ ^ invention to other virtual machine environments would 

programmatically, without having the source code used to be apparent to one skilled in the art. The preferred embodi- 

produce them available, and without needing to use a mem 0 f tne present invention assumes that the user has 

disassembler to derive the source code. available Java™ class files which have been compiled with 

As shown in FIG. 1, the class loader 120 is the component a compiler that adheres to the Java™ standard published by 

of a virtual machine environment which retrieves code to be 5Q Sun Microsystems and described in The Java Virtual 

executed. The code may all be loaded as the program Machine Specification , by Tim Lindholm and Frank Yellin, 

initializes, or may be loaded on an as-needed basis. The code Addison Wesley, 1997. The JOIE of the present invention 

may be loaded from local (e.g., disk drive) or remote (e.g., assumes the class files may be loaded for execution, but the 

over the Internet) storage. In cither case, the class loader 120 source code for the class files may not be available, or, if the 

< passes the class file 115 to the virtual machine 125, which 55 source code is available, the user does not wish to modify 

performs the bytecode verifier function then loads requested and recompile it. It is further assumed that the modifications 

code into the virtual machine 125 for execution. desired by the user may be expressed programmatically. 

One may desire to modify a class file as it is being loaded. The user identifies the modifications he wishes to have 

This could be done for reasons that include, but are not performed in class files by building a control file. The 

limited to, security, performance enhancement, adding addi- 60 control file contains a specification of the modifications to be 

tional function or instrumentation to the byte codes, or performed, written as a Java™ class which implements a 

changing the way the components of a program interact. The ClassTransformer interface. A class implementing 

present invention provides a method, system, and computer ClassTransformer provides two methods: 

program product for accomplishing said modification of 1) select: this method returns true if the class whose name 

class files as they are being loaded. 65 is provided by the caller is a valid target for transfor- 

The present invention extends the class loader to include mation. The user may write this class in any way he 

a programmatic class file modification function. This tunc- desires, including but not limited to: returning true for 
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all classes, returning true for all classes named in a list 
retrieved from a file or elsewhere, returning true for all 
classes that are not built into the Java™ environment, 
etc. 

2) transform: this method performs the actual transfor- 
mation. Note that no restriction is placed upon the 
mechanism of the transformation, and the mechanism 
of the transformation is not a subject of the present 
invention. The transform method accepts a class file as 
bytes, and returns a possibly-modified class file as 
bytes. 

The JOIE of the preferred embodiment provides methods 
for class file analysis and modification, which the user may, 
but is not required to, use in his select and transform 
methods. Some of these methods are derived from methods 
provided by Sun Microsystems' standard Java™ environ- 
ment in the java.lang. Class class and in the java.lang.reflect 
class hierarchy (which are documented in many generally 
available sources, including Java in a Nutshell, second 
edition, by David Flanagan, O'Reilly and Associates, May 
1997), and others are added by the JOIE of the preferred 
embodiment, and would be straightforward for one skilled in 
the Java™ art (with reference to The Java Virtual Machine 
Specification book cited above) to create. These provided 
analysis and modification methods reside in a new class 
provided by JOIE named Mirror. The user may elect not to 
use the Mirror class, and may substitute some other meth- 
odology for class file modification into the transform 
method. 

The Java™ program method of writing the control file 
allows virtually unlimited flexibility to the user. The user 
may make use of Java™ control statements, such as 
conditionals, to specify when certain changes are to be 
made, and how they are to be made. 

The contents of a hypothetical control file, which a user 
might create to cause a method to obtain the value of the first 
field in a class to be added to the class, are here illustratively 
shown: 



class Add Getter implements QassTransformer { 
boolean select(String name) { 
return true; 

} 

bytef ] transform(byteJ 1 bytes). { 

Minor mirror «* new Mirror(bytes) ; 
Modifier mod » new Modifter( ) ; 
modset(Modifier.PUBUC) ; 
Field! I " mirror. gelFields( ) ; 
String fieldname - fields[0].gctName( ) ; 
String methname - "get" + fieldname; 
String desc - "( )I"; 

short index - (short) mirror. findFieid(field name) ; 

byte[ ] code - new byte[5] ; 

code(0] - (byte) 0x2a; // aload_0 

codc(l] - (byte) 0xb4; // getfield 

code{2] » (byte) (index » 8) ; 

code{3] - (byte) (index & Oxflf) ; 

codc{4] - (byte) Oxac; // i return 

short code_index « (short)mirror.rind( t4 Codc'') ; 

Attribute_Code attc - new AUribute_Code((short)l, (shorty, 

code_indcx, code) ; 
mirror.addMethod(mod, methname, desc, attc) ; 
return mirror.getBytcs( ) ; 



} 



} 



20 



25 



30 



This illustrative control file will perform its transforma- 
tion on all class files loaded, as the select method always 
returns true. The transform method gets the list of fields in 
the class using Mirror's getFields method, obtains the name 



of the first field returned using the getName method of the 
java.lang.Field class, and then uses Mirror class methods to 
locate said first field and to add a method to the class to get 
the value of said first field. 
5 The class loader component of the Java™ Virtual 
Machine (JVM) which is specified by Sun Microsystems is 
user-extendible, with extensions made via the well-known 
technique of creating sub-classes of the class loader. The 
preferred embodiment of the present invention extends the 
10 class loader to contain an interface named QassTransformer. 
Users register ClassTrans formers with their instance of 
the extended ClassLoader. The user's class loader queries 
(by calling the select method) whether or not the class is a 
valid target for transformation. If the class is a valid target 
15 for transformation, the transformation is applied by calling 
the transform method. 

The user's class loader could implement additional 
straightforward extensions, for example to allow a series of 
transformations or to always provide an additional transfor- 
mation to transformed classes which mark them as imple- 
menting the interface Transformed. The additional Trans- 
formed interface would have no semantic effect, but could 
be used by user code to detect whether the class has in fact 
been modified. 

FIGS. 4 and 5 depict the extended class loader 445 of the 
preferred embodiment (FIG. 5 depicts in more detail the 
process resident in the QassTransformer interface 420). A 
class file to be loaded is obtained 405 from its repository 
400. The repository may be locally resident or accessed 
through a network. Before the class loader does any pro- 
cessing on the class file, its contents are passed 415 to the 
QassTransformer interface 420, which calls the user- 
provided select method to determine if the user-provided 
transform method should be run 505. If the user-provided 
select method returns true 510, the class file is passed to the 
user-provided transform method, which performs any modi- 
fications that may be required 515. Once the modified class 
file is returned from the JOIE extended class loader 435 and 
555, it is loaded normally by the linking process and treated 
as if it had been originally received in its modified form 440. 
What is claimed is: 

1. A computer-implemented method for enabling pro- 
grammatic semantic modifications to class files as said files 
are loaded for execution by a loading and execution process, 
said method comprising the steps of: 
providing an extended class loader; 
receiving, by said extended class loader, a request for 
loading a selected one of said class files, wherein said 
request is generated from an executing application 
program and wherein said selected class file contains 
executable program code to be executed as a part of 
said application program; 
retrieving, by said extended class loader, said selected 
class file; 

determining, by evaluating one or more specified condi- 
tions from a stored control file, whether said retrieved 
class file is to be semantically modified prior to an 
execution of said executable program code; 
if any of said conditions are met, performing the steps of: 
applying one or more semantic modifications to said 
executable program code in said retrieved class file 
by executing one or more stored transformations 
associated with said stored conditions, creating a 
65 dynamically modified class file; and 

delivering said dynamically modified class file as a 
result of said request; and 



40 
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50 
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if none of said conditions are met, delivering said 
retrieved class file as said result of said request. 

2. The computer-implemented method as claimed in claim 
1, wherein said class files are Java class files. 

3. The computer-implemented method as claimed in claim 
1, wherein said extended class loader extends a Java class 
loader. 

4. A computer program product for enabling program- 
matic semantic modifications to class files as said files are 
loaded for execution by a loading and execution process, 
said computer program product comprising: 

a computer-readable storage medium having computer- 
readable program code means embodied in said 
medium, said computer- read able program code means 
comprising: 

computer-readable program code means for providing 
an extended class loader, 

computer-readable program code means for receiving, 
by said extended class loader, a request for loading 
a selected one of said class files, wherein said request 
is generated from an executing application program 
and wherein said selected class file contains execut- 
able program code to be executed as a part of said 
application program; 

computer-readable program code means for retrieving, 
by said extended class loader, said selected class file; 

computer-readable program code means for 
determining, by evaluating one or more specified 
conditions from a stored control file, whether said 
retrieved class file is to be semantically modified 
prior to an execution of said executable program 
code; 

if any of said conditions are met, computer-readable 
program code means for: 

applying one or more semantic modifications to said 
executable program code in said retrieved class 
file by executing one or more stored transforma- 
tions associated with said stored conditions, cre- 
ating a dynamically modified class file, and 
delivering said dynamically modified class file as a 
result of said request; and 



10 
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25 



30 



35 



if none of said conditions are met, computer-readable 
program code means for delivering said retrieved 
class file as said result of said request. 

5. The computer program product as claimed in claim 4, 
wherein said class files are Java class files. 

6. The computer program product as claimed in claim 4, 
wherein said extended class loader extends a Java class 
loader. 

7. A computer system for enabling programmatic seman- 
tic modifications to class files as said files are loaded for 
execution by a loading and execution process, said system 
comprising: 

means for providing an extended class loader; 
means for receiving, by said extended class loader, a 
request for loading a selected one of said class files, 
wherein said request is generated from an executing 
application program and wherein said selected class file 
contains executable program code to be executed as a 
part of said application program; 
means for retrieving, by said extended class loader, said 

selected class file; 
means for determining, by evaluating one or more speci- 
fied conditions from a stored control file, whether said 
retrieved class file is to be semantically modified prior 
to an execution of said executable program code; 
if any of said conditions are met, means for: 

applying one or more semantic modifications to said 
executable program code in said retrieved class file 
by executing one or more stored transformations 
associated with said stored conditions, creating a 
dynamically modified class file; and 
delivering said dynamically modified class file as a 
result of said request; and 
if none of said conditions are met, means for delivering 
said retrieved class file as said result of said request. 

8. The computer system as claimed in claim 7, wherein 
said class files are Java class files. 

9. The computer system as claimed in claim 7, wherein 
said extended class loader extends a Java class loader. 
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